1. Field of the Invention
The present invention relates to identifying a part in a server where a plurality of processes competes for a resource. In particular, the present invention relates to a technique to identify conflicting processes in a server on the occurrence of a conflict attributable to concurrent processing of a plurality of transactions.
2. Description of the Related Art
A first related art is a technique described in Takashi Horikawa, “Performance Analysis of a Client-Server System Using Queueing Networks: A Case Study,” Int. Trans. Opl Res. Vol. 4, No. 3, pp. 199-209, 1997, and is a technique to evaluate the performance of a server that concurrently processes a plurality of transactions. In the first related art, an evaluation is made by using: basic performance data, which is the time spent on using a server resource (such as a CPU or a disk) for processing a single transaction; and a performance evaluation model based on the queuing network theory. By use of this technique, the performance of a server processing a plurality of transactions (mainly a relationship between the throughput of the server and the respective response times for the transactions) is evaluated.
A second related art uses a performance simulator as a performance evaluation model, and the performance of a server processing a plurality of transactions is evaluated on the basis of the time spent on using a server resource as in the first related art.
With the performance evaluation models used in the first and second related arts, performance is evaluated generally on the assumption that the following conditions are satisfied.
(1) Time spent on using a server resource for processing a single transaction remains unchanged even if the number of transactions to be processed by the server per unit of time varies.
(2) The resource for which a plurality of transactions compete is a server resource indicated by input data (basic performance data).
When a server that executes a program for processing transactions satisfies the conditions (1) and (2), a result obtained by using any of the performance evaluation models reflects the actual performance of the server. An example of such a result is a relationship between the throughput of the server and the respective response times for transactions.
On the other hand, when the conditions (1) and (2) are not satisfied, a result obtained by using any of the performance models does not reflect the actual performance of the server. For example, the performance of a server having a plurality of CPUs is evaluated by using a performance evaluation model in some cases, even when the server executes a program including a critical section during transaction processing. In such a case, the result of the evaluation shows higher performance than the actual performance of the server. In other words, the actual performance is poorer than the result obtained on the basis of the performance evaluation model. Incidentally, a critical section is a section that cannot be executed concurrently, in a session of a transaction processing program, and in a session of another transaction processing program.
A description is given of an example of a state where the server performance evaluated by use of a performance evaluation model does not reflect the actual performance of the server. FIG. 1 shows a progress of processing in the case where a server having four CPUs concurrently starts Processes 1 to 4 respectively of four transactions. A program executed by each of CPUs for processing the transaction (hereinafter, simply referred to as a transaction processing program) includes processes that can be processed concurrently with other processes, and processes that require mutual exclusion control. Mutual exclusion control may be enforced on the processes that require mutual exclusion control, by using a spin lock during transaction processing. One of the four CPUs obtains the right to execute a critical section process, while the remaining three CPUs are in a busy wait. The three CPUs cannot process transactions while being in a busy wait.
As shown in FIG. 1, transactions each including a critical section are executed respectively in Processes 1 to 4. Each of the transactions requires 3 sections of CPU time. In Process 1, a critical section process is executed from Time 1 to Time 2. Meanwhile, in Process 2, the CPU is in a busy wait from Time 1 to Time 2. Then, in Process 2, a critical section process is executed from Time 2 to Time 3. A critical section process starts from Time 3 in Process 3, and from Time 4 in Process 4. It takes 3 sections of CPU time to process a single transaction in Process 1, while the processing of transactions requires 4, 5 and 6 sections of CPU time in Processes 2, 3 and 4, respectively. Thus, 4.5 sections of CPU time are required on average to process a single transaction in the four CPUs. Hence, longer CPU time is required to process a single transaction in the above case than the case of processing a transaction including no critical section process.
In general, a process that requires mutual exclusion control does not constitute the entire transaction. A transaction comprises a series of a plurality of sub-processes, and a process that requires mutual exclusion control is applicable to one or some sub-processes of the transaction in many cases. Given this fact, desired is a method of reducing an effect of conflicts between a sub-process that requires mutual exclusion and other sub-processes, or a method of resolving conflicts between a sub-process that requires mutual exclusion and other sub-processes. By use of such a method, the discrepancy between the evaluated processing time and actual processing time can be resolved. Moreover, a server achieves performance as expected from an evaluation result based on a performance model. To reduce an effect of a conflict or to resolve a conflict, a combination of conflicting sub-processes needs to be identified.
However, there has been no method of identifying a combination of conflicting sub-processes, heretofore. Hence, an expert who has advanced knowledge has to check the operation of a server by using a combination of various measurement tools to identify conflicting sub-processes, and then, on the basis of the results and the expert's experience, a bottleneck in which sub-processes compete for a resource is estimated. Such a above technique has problems that a considerable amount of human resource is required, and that time spent on the identification process is likely to be long. Moreover, estimation results are not always correct, and estimated conflicting sub-processes are sometimes inaccurate. As a result, countermeasures taken afterwards come to nothing. Accordingly, the process of identifying a bottleneck in which sub-processes compete for a resource has been a factor of an increase in system building costs.